Access to resources in a virtual environment

ABSTRACT

Access to a resource in a virtual environment is controllably granted by:
         a) receiving, from a user of the environment, a request for access to the resource;   b) allocating the request to a queue of requests for the resource;   c) determining a maximum permissible rate of access of users to the resource;   d) providing a mechanism which is operable to grant users of the virtual environment with access to the resource at a rate no greater than the maximum permissible rate;   e) allocating requests from the queue to the mechanism at a controlled allocation rate no greater than the maximum permissible rate;   f) upon allocation of the request from the user to the mechanism, the mechanism granting the user with access to the resource within the virtual environment.

TECHNICAL FIELD

This invention relates to virtual environments, also known as virtualworlds, and to the accessing of resources in such environments.

BACKGROUND ART

Virtual environments (referred to herein interchangeably as “virtualworlds”) are typically implemented as server software accessible over anetwork, to which users may connect with suitable client software. Manyusers can connect simultaneously to interact with one another and withthe environment represented by the virtual world. A well-known andcurrently popular example of such a virtual world is called Second Life,which is hosted by Linden Lab of San Francisco, Calif., furtherinformation being available at www.secondlife.com.

It is increasingly common to have events hosted in virtual environments.Examples include music concerts and other entertainment acts which usersmay “attend” by moving their character or avatar within the virtualenvironment to a location or venue (just as in the real world). Theperformance is provided as an audio and/or video feed which isexperienced by the user within the virtual environment.

Problems can arise when large numbers of users want to simultaneouslyattend an event in a virtual environment. This is typically due to thefact that the event is managed by a server and because users at the sameevent typically draw on the same software and hardware resources.Generalising the problem, large numbers of users accessing the sameserver resource can cause server overload, and this can result in theserver crashing or performance being adversely affected, so that usersexperience lag and stutter in the representation of and interaction withthe virtual environment.

Even where an event is engineered to cater for a sufficient number ofusers (for example in the tens or hundreds of thousands), problems canarise from a sudden flood of access attempts occurring simultaneously,particularly if the demand is estimated incorrectly and there is a delayin bringing a sufficient number of additional servers online to copewith the demand.

DISCLOSURE OF THE INVENTION

There is provided a method of providing access to a resource in avirtual environment, comprising the steps of:

a) receiving, from a user of the environment, a request for access tothe resource;

b) allocating the request to a queue of requests for the resource;

c) determining a maximum permissible rate of access of users to theresource;

d) providing a mechanism which is operable to grant users of the virtualenvironment with access to the resource at a rate no greater than themaximum permissible rate;

e) allocating requests from the queue to the mechanism at a controlledallocation rate no greater than the maximum permissible rate;

f) upon allocation of the request from the user to the mechanism, themechanism granting the user with access to the resource within thevirtual environment.

The method stores requests in a queue, and controls the rate at whichthey are released from the queue to an access mechanism so that thisallocation rate is not greater than a maximum permissible rate. In thisway, limits on the resource access rate can be enforced backwards ontothe queue so that the loading of access requests to the resource neverexceeds a desired rate.

Preferably, the request is received from a server associated withhosting the environment.

Alternatively, the request may be received from a channel unrelated tothe hosting of the environment and is associated with the user.

For example, the request may be received as a telephone or emailcommunication and contain an identifier from which the user may beidentified.

The request may be allocated to a prioritized position within the queue,and in this way, preferential treatment can be given to groups of usersor other access control policies enforced.

Preferably, the method further comprises the step of validating therequest before allocating the request to the queue. In this way, invalidor spurious requests can be weeded out at an early stage, so that onlythose requests determined to be valid are actually referred to theaccess mechanism. As an example, if a user has a history of registeringto access resources but failing to take up the offer of access whengranted, then such a user can be blacklisted from accessing resourceswhich have a high degree of competition for access.

Optionally, a number of queues may be maintained for the resource, andthe method can further comprise the step of selecting a queue to whichthe request is allocated.

This will enable different types of access to be granted to differentclasses of user, or allow users to be segregated into fast and slowqueues as appropriate. In a multinational community, it might be desiredto grant access to a resource fairly to users from all countries on aper capita basis, for instance. This could be achieved by maintaining aqueue for each country, with users being segregated into queuesaccording to IP address ranges (used as a determinant of thegeographical source of the request), and limits could be imposed on eachqueue to ensure that the quotas were respected. Many other scenarioswill readily suggest themselves to the skilled person.

The maximum permissible rate of access can be received as a manualinput. In this way, network administrators or supervisors can controlthe rate at which they wish to grant access to the resource.

Alternatively or additionally, the maximum permissible rate of accesscan be determined with reference to a measurable capacity associatedwith the resource.

Preferably, the resource is hosted by or accessible via one or moreservers and the maximum permissible rate of access is determined atleast in part with reference to the capacity of the one or more servers.

For example, the capacity of the one or more servers may be determinedas a function of the number of servers hosting or providing access tothe resource.

The method may also include the step of adjusting the maximumpermissible rate of access as the measurable capacity associated withthe resource is varied.

Thus, in a multi-server environment, the rate of access can be increasedor decreased with the number of servers currently online, or can bevaried in response to the server processing load available to host theresource in question.

The method may further include requesting the introduction of additionalcapacity in association with the resource in the event that thecontrolled allocation rate reaches a predetermined relationship with themaximum permissible rate.

The method may also or alternatively include the step of requesting theintroduction of additional capacity in association with the resource inthe event that a measured queue load reaches a threshold.

The request for the introduction of additional capacity can be effectiveto bring additional server capacity online to represent the resource towhich access has been requested.

This option can be used to provide a self-correcting, feedbackcontrolled server loading, with additional servers being automaticallybrought into play if there is a surge in demand for access to theresource, in contrast to the current situation in which this must beanticipated manually in advance. Until such servers are brought intoplay, the rate of access is artificially limited to the maximumpreferred rate in order to safeguard the server load and the networktraffic load.

The mechanism is preferably provided as a plurality of virtual agents oras a plurality of interfaces to human agents, wherein the controlledallocation rate is driven by the rate at which the agents become free tohandle new requests from the queue.

In one embodiment, the mechanism is implemented as one or more virtualagents which are each configured to interact with one or more user(s) asthe user(s) are granted access to the resource, the rate at which usersare granted access to the resource being determined by the number ofvirtual agents and the number of users with whom each virtual agentinteracts simultaneously.

The virtual agents can be provided as a plurality of instances of thesame software-generated virtual agent.

It will be appreciated that using virtual agents, which interact withusers as they are provided with access to the resource, allows thenumber of agents to be used as a rate limiting factor according to whichthe rate of operation of the mechanism is throttled.

Alternatively, the mechanism may be implemented as an interface enablingeach of a plurality of human agents to interact with one or more user(s)as the user(s) are granted access to the resource, the rate at which theusers are granted access to the resource being determined by the numberof the human agents and the number of the users with whom each agentinteracts simultaneously.

Preferably, the step of granting the user with access to the resourcecomprises altering the virtual environment as experienced by the user.

This can be done in many different ways, including bringing the userinto a restricted “area” of the virtual environment, ensuring that auser is ready to take up a place by creating an interaction for theuser, providing an automated or human-driven “usher” who accompanies theone or more users to their seats in a concert, and so on.

The environment can be altered in different ways for different classesof user, so that, for example, a concert by a single performer in avirtual environment is experienced by users from London as taking placein Wembley Stadium, while being experienced by users from New York astaking place in Madison Square Gardens, for instance.

There is also provided a computer program product comprising a computerreadable medium encoding instructions which, when executed in acomputing system, are effective to cause the computing system to performthe aforesaid methods of providing access to a resource in a virtualenvironment.

It will be appreciated that the methods disclosed herein are preferablycomputer-implemented, i.e. programmed into software which runs onsuitably configured computer systems in order to provide the access tothe resource. The computer systems may be stand-alone systems ordistributed over a network. They can be general purpose personalcomputers or servers, or they can be dedicated, configured machines. Thesoftware can be provided on any computer-readable medium, includingoptical and magnetic disks, solid-state memories, hardwired in anelectronic circuit, implemented as firmware, or provided as anelectronic signal, e.g. over the Internet. For the queuing aspects ofthe method, appropriate contact center or call center systems may beadapted for use with the mechanism providing access to the virtualenvironment.

We also provide a system for providing access to a resource in a virtualenvironment, the system comprising:

a) an interface for receiving requests for access to the resource;

b) a queuing manager controlling a queue of the requests for access tothe resource;

c) a memory storing a maximum permissible rate of access of users to theresource;

d) a mechanism configured to grant users of the virtual environment withaccess to the resource at a rate no greater than the maximum permissiblerate;

-   -   wherein the queuing manager is configured to allocate requests        from the queue to the mechanism at a controlled allocation rate        no greater than the maximum permissible rate; and    -   wherein the mechanism is effective to grant the user with access        to the resource within the virtual environment upon allocation        of the request from the user to the mechanism.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention will now be further illustrated by the followingdescriptions of embodiments thereof, given by way of example only withreference to the accompanying drawings, in which:

FIG. 1 is a block diagram architecture of a first system for providingaccess to a resource in a virtual environment;

FIG. 2 is a flowchart showing the allocation of a request to a queue;

FIG. 3 is a flowchart showing the granting of access in accordance withqueued requests;

FIG. 4 is a flowchart showing the dynamic adjustment of the rate ofgranting access to a resource; and

FIG. 5 is a block diagram architecture of a second system for providingaccess to a resource in a virtual environment.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

In FIG. 1 there is indicated, generally at 10, a system for providingaccess to a resource in a virtual environment or virtual world hosted ona group of co-operating servers 12. In addition to hosting theenvironment itself, a subset 14 of servers is dedicated to providing anevent for users to attend within the virtual environment, such as apolitical rally, a product launch, a concert, or an appearance by acelebrity. The servers 14 could equally provide access to any other sortof resource to which users would want access, such as an exclusive areaof the virtual world, the use of an item or service within the virtualenvironment, access to a broadcast, and so on.

Users 16 access the virtual environment via the Internet 18 or any othersuitable communications channel. As is well known, users areauthenticated for access to the virtual environment, and can requestaccess to limited resources within that environment (such as the eventhosted by servers 14) using any appropriate in-character orout-of-character mechanism provided in the virtual environment. Requestsfor services can be conveyed through other channels, such as bypurchasing an option in an account management website, or by verballyrequesting, over the telephone, an operator associated with themanagement of the virtual environment to provide access. Suchalternative channel requests need only be associated with the identityof the user to be acted on in exactly the same manner as in-worldrequests.

The handling of such requests and the granting or denial of access ismanaged by a queuing manager 20 and a further server 22 which hostssoftware (or virtual) agents to interact with users when grantingaccess, in the manner which will now be described in conjunction withFIGS. 2 and 3.

Referring additionally to FIG. 2, a request for access to a limitedresource is received in step 40. The request can be made in a parallelchannel as described above, or can be made by the user interacting withthe environment (such as by controlling a character or avatar), e.g. byissuing an appropriate command, verbally requesting access, making aparticular gesture or moving into a marked area, interacting with anappropriate mechanism or in any other way. The user may not even beaware that the request has been made (e.g. if a world's administratorswant to improve the quality of dialog typed by users, access to alimited resource might be granted as a prize, with users unknowinglysubmitting a request for that prize when key phrases are spoken).

Optionally, step 42, the request is validated to ensure that permissioncan be granted for that request. As a simple example, one might deny arequest, step 44, to any user whose account was in arrears.

If valid, a determination is made as to whether there is more than onequeue for such requests, decision 46. Multiple queues can be employedfor many reasons, discussed previously, and if multiple queues are usedthen a determination is made as to which is the appropriate queue forthe request under consideration, step 48.

Referring back to FIG. 1, it can be seen that the queuing managermaintains various resources, implemented using appropriately programmedsoftware. Thus, a request database or memory 24 stores details of therequests themselves, supplemented as necessary with details of the usersubmitting the request, obtainable from the virtual world servers 12 orassociated account records. Validation rules 26 determine whether or notthe requests are valid. One or more queue structures 28 are alsoprovided and maintained, with requests (or details of requests) beingadded to the queues and processed when they reach the top of such queuesby the queue manager operating under programmed rules.

Returning to FIG. 2, if all requests are not given equal priority, adetermination is made, decision 50, as to whether the request underconsideration is a priority request. If so, the request is added to aqueue at an appropriate position to take account of the assignedpriority, step 52. Otherwise, step 54, it is added to the tail end ofthe queue in a “first come, first served” manner. Requests are held inthe queue until it is almost time to grant access to the resource (e.g.shortly before a concert is about to begin), step 56, assuming thataccess to the resource is not already being granted. Any queuingtechnique can be used, including LIFO (last in, first out).

Referring to FIG. 3, when it is time to begin granting access to theresource, step 60, a determination is firstly made by virtual agentserver 22 as to what server resources are available on the event servers14 to accept users when granted access, step 62. The resources can bemeasured in terms of the number of servers, the expected server load,the available processing power or memory on the servers, or using anyother appropriate metric.

Based on the expected server resources and knowledge of the accessmechanism which will be provided to users, an initial maximum permittedrate of access to the resource is set in step 64. Based on this accessrate, an appropriate number of automated agents is initialised. Thenumber of agents required will depend on, among other things, theefficiency of such agents, the degree of interaction with users requiredto grant access in accordance with the wishes of the system designers,the number of users to whom an automated agent can grant access at onetime, and so on.

The number and identity of the automated agents is updated, step 68, inan agent resources database 30 (FIG. 1). The queuing manager uses thisset of agent resources to keep track of the agents to which it canassign requests from the queues 28. As agents are added or removed, andas they are assigned and complete requests, the records of agentresource database 30 are updated accordingly.

The maximum permitted rate of access can be enforced by limiting thenumber of agents available to handle requests, or it can be enforced byprogramming the agents to operate to a maximum aggregate rate ofgranting access. In this way, the queuing manager can be configured toassign requests from the queue(s) 28 to agent resources 30 as and whenthe agent resources are available (or as they indicate theiravailability if they are working at an artificially enforced rate).

Thus, in operation, the queuing manager waits until the next agent isready, step 70 (FIG. 2) then serves the next request at the top of thequeue to the next available agent, step 72, and the agent resources areupdated to indicate that this agent is now servicing that request, step68.

The automated agent, on being assigned a request, contacts the user,step 74. In practice this may be accomplished by the automated agenthaving an in-world presence or avatar, which is similar to a non-playercharacter or NPC. This NPC can appear in the field of vision of the userwho submitted the request (by appropriate co-operation between virtualagent server 22 and the overall hosting servers 12), and can interactwith the user's character offering the opportunity to fulfil the pendingrequest for access to a resource.

In the illustrated embodiment of FIG. 3, the user is asked to confirmhis or her availability to access the resource when the offer is made(the user could be otherwise busy, or away from their keyboard, forinstance). If the user is ready, decision 78, the agent instructs thehosting servers 12 to “teleport” the user and agent together into therestricted area—in other words, updating the virtual world locationcoordinates of the of the user, which may involve logging the user on tothe dedicated event servers and those servers generating an appropriateenvironment, step 80.

Once the user has been granted access in accordance with whatever rulesare set up by the system designers (it being appreciated that the notionof teleporting into a closed area is simply one of a myriad ofpossibilities for granting access to a resource), and assuming that thecurrent aggregate rate of granting access is not exceeding the maximumpermissible rate, the agent can indicate that it is free again for thenext user, step 82, and this fact is notified back to the agentresources, 68, which will then note the agent is free in step 70, and soon.

If the user does not indicate readiness in decision 78, then severaloptions are open to the agent, as indicated in step 84. For example, therequest can simply be discarded, or the agent can await a timeout periodfor the user to indicate readiness to proceed, or the request can bere-queued, in whatever position is appropriate.

FIG. 4 illustrates options for adjusting the maximum permissible rate.In step 90, the access granting process of FIG. 2 is in progress. Atsome point, an alert is generated, such as an alert that the queue loadexceeds a threshold (more users are seeking to access the resource thananticipated), step 92, or an alert that the allocation rate from thequeue is approaching the maximum permissible rate (i.e. the automatedagents are working as fast as they can to clear requests from thequeue), step 94. Neither situation is necessarily problematic, but theyeach indicate that user waiting time could be decreased by increasingthe maximum permitted rate.

A first determination 98 is made as to whether there are in fact anymore agents available. While such a determination is more likely to benegative in embodiments employing live 20 human agents, such as theembodiment of FIG. 5 described below, the automated agent server 22could be working at maximum capacity and could be unable to instantiateany additional agents without the current performance taking an adversehit. If no agents are available, the allocation rate from the queue tothe agents is limited at the maximum permitted rate, as before and theprocess reverts to step 90.

However, if it is determined that more agents are available, thisindicates that the maximum permitted rate might usefully be increased.This makes sense, however, only if the server(s) providing the resourcein question can handle an increased access rate, decision 100. If theycan handle more frequent access, then additional agents are added (orthe work rate of the agents is increased), step 102, and the maximumpermitted rate is increased to a new appropriate level, step 104.

If the current server resources could not handle the available extraagents, then a determination is made, decision 106, as to whethergreater server capacity is available. Referring back to FIG. 1momentarily, the current server load is measured by a feedback mechanism34, and it can be seen that there are excess server resources 32indicated as being available for addition to the live server capacity12, 14 or 16.

In the context of decision 106 (FIG. 4), such servers will be added tothe event server capacity, step 108. Upon an increase in servercapacity, the max permissible rate can be increased directly, step 104,or the system can follow up by immediately adding more agents to takeadvantage of this additional capacity (branching to step 102 rather than104, not shown).

Additional server capacity can be introduced not just by adding extraservers, but also by increasing resources available to the eventservers, e.g. transferring other processes elsewhere on the network.

Finally, FIG. 5 shows an alternative embodiment to that of FIG. 1 but inwhich like entities are indicated by like reference numerals for ease ofunderstanding.

The automated or virtual agents of FIG. 1 are omitted in FIG. 5 in favorof a number (possible a very large number) of live human agents 36,indicated by workstations connected to an agent local area network (LAN)38. Such agents can operate in similar fashion to the automated agentsof FIG. 1, interacting with those users for whom they have beenallocated requests from the queuing manager 20. The identity and statusof each agent is recorded in the agent resources database 30, just asfor the virtual agents. The agent workstations allow the agents tocommunicate with users in the virtual environment, and the rate at whichthey grant users access can be readily controlled by limiting access tothe environment, or by throttling the allocation rate of requests tobelow the maximum permitted rate. The maximum permitted rate can also bereduced or increased by removing or adding agents to the pool of agentsservicing requests from the queues 28.

The invention is not limited to the embodiments described herein whichmay be varied or modified without departing from the scope of theinvention.

1. A method of providing access to a resource in a virtual environment,comprising the steps of: a) receiving, from a user of said environment,a request for access to said resource; b) allocating said request to aqueue of requests for said resource; c) determining a maximumpermissible rate of access of users to said resource; d) providing amechanism which is operable to grant users of said virtual environmentwith access to said resource at a rate no greater than said maximumpermissible rate; e) allocating requests from said queue to saidmechanism at a controlled allocation rate no greater than said maximumpermissible rate; f) upon allocation of said request from said user tosaid mechanism, said mechanism granting said user with access to saidresource within the virtual environment.
 2. A method as claimed in claim1, wherein said request is received from a server associated withhosting said environment.
 3. A method as claimed in claim 1, whereinsaid request is received from a channel unrelated to the hosting of saidenvironment and is associated with said user.
 4. A method as claimed inclaim 3, wherein said request is received as a telephone or emailcommunication and contains an identifier from which said user may beidentified.
 5. A method as claimed in claim 1, wherein said request isallocated to a prioritized position within the queue.
 6. A method asclaimed in claim 1, further comprising the step of validating saidrequest before allocating said request to said queue.
 7. A method asclaimed in claim 1, wherein a number of queues are maintained for saidresource, and further comprising the step of selecting a queue to whichsaid request is allocated.
 8. A method as claimed in claim 1, whereinsaid maximum permissible rate of access is received as a manual input.9. A method as claimed in claim 1, wherein said maximum permissible rateof access is determined with reference to a measurable capacityassociated with said resource.
 10. A method as claimed in claim 9,wherein said resource is hosted by or accessible via one or more serversand said maximum permissible rate of access is determined at least inpart with reference to the capacity of said one or more servers.
 11. Amethod as claimed in claim 10, wherein said capacity of said one or moreservers is determined as a function of the number of said one or moreservers hosting or providing access to said resource.
 12. A method asclaimed in claim 10, further comprising the step of adjusting saidmaximum permissible rate of access as said measurable capacityassociated with said resource is varied.
 13. A method as claimed inclaim 1, further comprising the step of requesting the introduction ofadditional capacity in association with said resource in the event thatthe controlled allocation rate reaches a predetermined relationship withthe maximum permissible rate.
 14. A method as claimed in claim 1,further comprising the step of requesting the introduction of additionalcapacity in association with said resource in the event that a measuredqueue load reaches a threshold.
 15. A method as claimed in claim 1,wherein said mechanism is provided as a plurality of virtual agents oras a plurality of interfaces to human agents, and wherein saidcontrolled allocation rate is driven by the rate at which said agentsbecome free to handle new requests from said queue.
 16. A method asclaimed in claim 1 wherein said mechanism is implemented as one or morevirtual agents which are each configured to interact with one or moreuser(s) as the user(s) are granted access to the resource, the rate atwhich users are granted access to said resource being determined by thenumber of virtual agents and the number of users with whom each virtualagent interacts simultaneously.
 17. A method as claimed in claim 16,wherein said virtual agents are provided as a plurality of instances ofthe same software-generated virtual agent.
 18. A method as claimed inclaim 16, wherein said mechanism is implemented as an interface enablingeach of a plurality of human agents to interact with one or more user(s)as the user(s) are granted access to the resource, the rate at whichsaid users are granted access to said resource being determined by thenumber of said human agents and the number of said users with whom eachagent interacts simultaneously.
 19. A method as claimed in claim 1,wherein the step of granting said user with access to said resourcecomprises altering the virtual environment as experienced by said user.20. A method as claimed in claim 1, wherein said request is generated asa result of an online transaction.
 21. A computer program productcomprising a computer readable medium encoding instructions which, whenexecuted in a computing system, are effective to cause said computingsystem to perform a method of providing access to a resource in avirtual environment, by: a) receiving, from a user of said environment,a request for access to said resource; b) allocating said request to aqueue of requests for said resource; c) determining a maximumpermissible rate of access of users to said resource; d) providing amechanism which is operable to grant users of said virtual environmentwith access to said resource at a rate no greater than said maximumpermissible rate; e) allocating requests from said queue to saidmechanism at a controlled allocation rate no greater than said maximumpermissible rate; f) upon allocation of said request from said user tosaid mechanism, said mechanism granting said user with access to saidresource within the virtual environment.
 22. A system for providingaccess to a resource in a virtual environment, the system comprising: a)an interface for receiving requests for access to said resource; b) aqueuing manager controlling a queue of said requests for access to saidresource; c) a memory storing a maximum permissible rate of access ofusers to said resource; d) a mechanism configured to grant users of saidvirtual environment with access to said resource at a rate no greaterthan said maximum permissible rate; wherein said queuing manager isconfigured to allocate requests from said queue to said mechanism at acontrolled allocation rate no greater than said maximum permissiblerate, and wherein said mechanism is effective to grant said user withaccess to said resource within the virtual environment upon allocationof said request from said user to said mechanism.